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Generic Routing Encapsulation (GRE) 


Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This document specifies a protocol for performing encapsulation of an 
arbitrary network layer protocol over another arbitrary network layer 
protocol. 


Introduction 


A number of different proposals [RFC 1234, RFC 1226] currently exist 
for the encapsulation of one protocol over another protocol. Other 
types of encapsulations [RFC 1241, SDRP, RFC 1479] have been proposed 
for transporting IP over IP for policy purposes. This memo describes 
a protocol which is very similar to, but is more general than, the 
above proposals. In attempting to be more general, many protocol 
specific nuances have been ignored. The result is that this proposal 
is may be less suitable for a situation where a specific "X over Y" 
encapsulation has been described. It is the attempt of this protocol 
to provide a simple, general purpose mechanism which is reduces the 
problem of encapsulation from its current O(n%*2) problem to a more 
manageable state. This proposal also attempts to provide a 
lightweight encapsulation for use in policy based routing. This memo 
explicitly does not address the issue of when a packet should be 
encapsulated. This memo acknowledges, but does not address problems 
with mutual encapsulation [RFC 1326]. 


In the most general case, a system has a packet that needs to be 
encapsulated and routed. We will call this the payload packet. The 
payload is first encapsulated in a GRE packet, which possibly also 
includes a route. The resulting GRE packet can then be encapsulated 
in some other protocol and then forwarded. We will call this outer 
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protocol the delivery protocol. The algorithms for processing this 
packet are discussed later. 


Overall packet 


The entire encapsulated packet would then have the form: 


Packet header 
The GRE packet header has the form: 


0 1 2 3 

O01 2.3: AD 26: P89 OT 234 Go T 8 OO 1 2 3 a. 6.7 89 OT 
SRF R HOFF ttt attr tata tatatatatatatatatata tata tata tat 

s|Recur| Flags | ver | Protocol Type 

E a e tbr tata t ttt tata ta tatatatatatata tata ta tat 
Checksum (optional) | Offset (optional) 

Fatt tata tartar tartar t ar tanta tanta tata ttt tata tata tatatatatatatatatat 

| Key (optional) | 

E a ea o tata tata tata a E G S tata tata E a a S DE E I a G A 

| Sequence Number (optional) 

Fatt ata t atta tartar t arta tanta tata tt tbat tat ata tatatatatatatatat 

| Routing (optional) 

Fatt ata t ata tartan tanta tanta tata ttt ata tata ta tatatatatatatatatat 


Flags and version (2 octets) 


The GRE flags are encoded in the first two octets. Bit 0 is the 
most significant bit, bit 15 is the least significant bit. Bits 
13 through 15 are reserved for the Version field. Bits 5 through 
12 are reserved for future use and MUST be transmitted as zero. 
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Checksum Present (bit 0) 


If the Checksum Present bit is set to 1, then the Checksum field 
is present and contains valid information. 


If either the Checksum Present bit or the Routing Present bit are 
set, BOTH the Checksum and Offset fields are present in the GRE 
packet. 


Routing Present (bit 1) 


If the Routing Present bit is set to 1, then it indicates that the 
Offset and Routing fields are present and contain valid 
information. 


If either the Checksum Present bit or the Routing Present bit are 
set, BOTH the Checksum and Offset fields are present in the GRE 
packet. 


Key Present (bit 2) 


If the Key Present bit is set to 1, then it indicates that the Key 
field is present in the GRE header. Otherwise, the Key field is 
not present in the GRE header. 


Sequence Number Present (bit 3) 


If the Sequence Number Present bit is set to 1, then it indicates 
that the Sequence Number field is present. Otherwise, the 
Sequence Number field is not present in the GRE header. 


Strict Source Route (bit 4) 


The meaning of the Strict Source route bit is defined in other 
documents. It is recommended that this bit only be set to 1 if 
all of the the Routing Information consists of Strict Source 
Routes. 


Recursion Control (bits 5-7) 

Recursion control contains a three bit unsigned integer which 
contains the number of additional encapsulations which are 
permissible. This SHOULD default to zero. 

Version Number (bits 13-15) 


The Version Number field MUST contain the value 0. Other values 
are outside of the scope of this document. 
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Protocol Type (2 octets) 


The Protocol Type field contains the protocol type of the payload 

packet. In general, the value will be the Ethernet protocol type 

field for the packet. Currently defined protocol types are listed 
below. Additional values may be defined in other documents. 


Offset (2 octets) 


The offset field indicates the octet offset from the start of the 
Routing field to the first octet of the active Source Route Entry 
to be examined. This field is present if the Routing Present or 
the Checksum Present bit is set to 1, and contains valid 
information only if the Routing Present bit is set to 1. 


Checksum (2 octets) 

The Checksum field contains the IP (one’s complement) checksum of 
the GRE header and the payload packet. This field is present if 
the Routing Present or the Checksum Present bit is set to 1, and 
contains valid information only if the Checksum Present bit is set 
to 1. 

Key (4 octets) 


The Key field contains a four octet number which was inserted by 


the encapsulator. It may be used by the receiver to authenticate 
the source of the packet. The techniques for determining 
authenticity are outside of the scope of this document. The Key 


field is only present if the Key Present field is set to 1. 


Sequence Number (4 octets) 


The Sequence Number field contains an unsigned 32 bit integer 
which is inserted by the encapsulator. It may be used by the 
receiver to establish the order in which packets have been 
transmitted from the encapsulator to the receiver. The exact 
algorithms for the generation of the Sequence Number and the 
semantics of their reception is outside of the scope of this 
document. 


Routing (variable) 


The Routing field is optional and is present only if the Routing 
Present bit is set to l. 
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The Routing field is a list of Source Route Entries (SRES). Each 
SRE has the form: 


0 1 2 3 
O21 22: 3 46926" P89" 0 AB 3 ANS. 6.7 (8: 9° O82) 3. ANS. 26> Tg 9 Od 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Address Family | SRE Offset | SRE Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Routing Information 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The routing field is terminated with a "NULL" SRE containing an 
address family of type 0x0000 and a length of 0. 


Address Family (2 octets) 


The Address Family field contains a two octet value which indicates 
the syntax and semantics of the Routing Information field. The 
values for this field and the corresponding syntax and semantics for 
Routing Information are defined in other documents. 


SRE Offset (1 octet) 
The SRE Offset field indicates the octet offset from the start of the 


Routing Information field to the first octet of the active entry in 
Source Route Entry to be examined. 


SRE Length (1 octet) 


The SRE Length field contains the number of octets in the SRE. If 
the SRE Length is 0, this indicates this is the last SRE in the 
Routing field. 


Routing Information (variable) 


The Routing Information field contains data which may be used in 
routing this packet. The exact semantics of this field is defined in 
other documents. 


Forwarding of GRE packets 


Normally, a system which is forwarding delivery layer packets will 
not differentiate GRE packets from other packets in any way. 

However, a GRE packet may be received by a system. In this case, the 
system should use some delivery-specific means to determine that this 
is a GRE packet. Once this is determined, the Key, Sequence Number 
and Checksum fields if they contain valid information as indicated by 
the corresponding flags may be checked. If the Routing Present bit 
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is set to 1, then the Address Family field should be checked to 
determine the semantics and use of the SRE Length, SRE Offset and 
Routing Information fields. The exact semantics for processing a SRE 
for each Address Family is defined in other documents. 


Once all SREs have been processed, then the source route is complete, 
the GRE header should be removed, the payload’s TTL MUST be 
decremented (if one exists) and the payload packet should be 
forwarded as a normal packet. The exact forwarding method depends on 
the Protocol Type field. 


Current List of Protocol Types 


The following are currently assigned protocol types for GRE. Future 
protocol types must be taken from DIX ethernet encoding. For 
historical reasons, a number of other values have been used for some 
protocols. The following table of values MUST be used to identify 
the following protocols: 


Protocol Family PTYPE 
Reserved 0000 
SNA 0004 
OSI network layer OOFE 
PUP 0200 
XNS 0600 
IP 0800 
Chaos 0804 
RFC 826 ARP 0806 
Frame Relay ARP 0808 
VINES OBAD 
VINES Echo OBAE 
VINES Loopback OBAF 
DECnet (Phase IV) 6003 
Transparent Ethernet Bridging 6558 
Raw Frame Relay 6559 
Apollo Domain 8019 
Ethertalk (Appletalk) 809B 
Novell IPX 8137 
RFC 1144 TCP/IP compression 876B 
IP Autonomous Systems 876C 
Secure Data 876D 
Reserved FFFF 


See the IANA list of Ether Types for the complete list of these 
values. 


URL = ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers. 
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Security Considerations 


Security issues are not discussed in this memo. 
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